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(54) Multiple command set support for rendering components. 

(57) A method and apparatus for supporting multiple command sets in a single rendering adapter. A device 
driver operating in tandem with a rendering adapter and its associated microcode interprets disparate 
command sets without separate control/interpretation sections being maintained in the rendering 
adapter. Rendering adapter microcode in the adapter for supporting a first command set is extending to 
support commands in a second command set not capable of being mapped in the first command set. The 
device driver receives the disparate data stream command sets generated by application programs and 
destined for the rendering adapter. If a first command set command is received by the device driver, it is 
grassed on to the rendering adapter substantially unmodified. If a second command set command is 
received by the device driver, an attempt is made to map the command into a first command set 
command, and then transfer this mapped command to the rendering adapter. If no mapping is possible, 
the received command is reformatted to conform to the syntax of the first command set, and then sent to 
the rendering adapter. As the rendering adapter microcode has been extending beyond interpreting and 
executing the first command set, this reformatted second command set command can be processed by 
the same parser resident in the rendering adapter microcode. 
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This invention pertains to the field of data proc- 
essing systems, and more specifically to ihe con- 
struction and interpretation of command data streams 
used to controi rendering components in a data proc- 
essing system. 

Various data processing rendering components 
are known in the prior art. Such components translate 
a series of instructions/commands into specific ren- 
dering operations. A graphics adapter acts as an in- 
terface between a computer and a computer display 
device. The graphics adapter accepts drawing com- 
mands from a data processing computer or micropro- 
cessor, translates these commands, and generates 
the appropriate driving signals used to drive and dis- 
play an image on a computer display. A printer adapter 
similarly accepts printing commands, interprets these 
commands, and generates the driving signals used to 
actuate the printer's electrical, electromagnetic, 
and/or laser-controlled print engine. 

These types of adapters are designed to accept 
a known and defined syntax or command set. Exam- 
ples of such graphics command sets are PHIGS, GL, 
and GKS. These command sets contain the actual 
drawing commands used to generate graphical dis- 
plays on a data processing systems' display device. 
Examples of data streams sent to a rendering printer 
adapter are Postscript 1 (Trademark of Adobe Sys- 
tems, Inc.) and IPDS. The rendering commands sent 
to a rendering adapter are generated from some type 
of command generator. This command generator 
could be, for example, a drawing/rendering applica- 
tion program running on a data processing computer. 
Such an application program could be running either 
locally within the same processing system which con- 
tains the graphics adapter, or remotely where the ap- 
plication program is running on a processing system 
separate from the system containing the graphics 
adapter and display. In the remote configuration, 
drawing commands would be transmitted from the ap- 
plication processing system to the drawing system via 
conventional telecommunications techniques. Vari- 
ous command sets have evolved over the years which 
correspond to changes in graphics adapter technolo- 
gy. For example, early command sets supported 2-di- 
mensional graphics adapters, which were only capa- 
ble of displaying 2-dimensional objects. Technologi- 
cal improvements in electronic packaging density 
have resulted in 3-dimensional graphics adapters be- 
ing introduced into the marketplace. As existing 2-d 
command sets could not take advantage of the new 
functionality contained 

Within these 3-d graphics adapters, new com- 
mand sets were created to support these 3-d graphics 
adapters. In addition, differing 3-d command sets 
have evolved which conform to various industry de- 
facto and international standards. These graphics 
adapters have generally been designed to handle a 
single type of command set This single-command set 



support was required to maximize the performance of 
the graphics adapter's ability to accept drawing com- 
mands and render a drawing on the processing sys- 
tem display or printer. This single-command set sup- 

5 port was also desired in order to minimize system 
costs, as the number and complexity of rendering 
adapter components increases substantially if more 
than a single command set were to be supported. This 
is due to increases in control circuitry and/or render- 

10 ing adapter microcode required to detect and interpret 
muitipie command set data streams. In general, a giv- 
en user environment does not want the increased 
overhead and associated performance degradation 
when the processing system actually being used is 

15 generating a single command set. Providing a multi- 
cornmand set function causes an end-user to unnec- 
essarily shoulder an increase in system overhead and 
cost. 

However, some end-users do have a need for 

20 supporting multiple command sets, and are willing to 
pay the costs and absorb the performance degrada- 
tions associated with such multi-command set sup- 
port To meet this demand of supplying multiple com- 
mand set functionality, prior art systems have provid- 

25 ed two distinct command set interpreters in the ren- 
dering adapter, one for each respective command set. 
This has resulted in a substantial increase in cost over 
and above a single command set rendering adapter. 
This increase in cost results from increases in volatile 

30 and/or nonvolatile data processing memory and other 
control electronics used to switch between command 
sets efficiently in order to minimize the resultant sys- 
tem performance degradation. 

In accordance with the present invention, there is 

35 now provided a method for providing multi-command 
support in a rendering adapter, comprising: 

receiving first commands of a first command 
set by an intermediate driver and providing the first 
commands to a rendering adapter; and 

40 receiving second commands of a second com- 

mand set by the intermediate driver, converting any 
of the second commands into resulting first command 
set commands and providing the resulting first com- 
mand set commands to the rendering adapter. 

45 The present invention provides a method and ap- 

paratus for supporting muitipie command sets in a 
single rendering adapter. The present invention there- 
fore provides a system which can support multiple 
command sets for a rendering adapter in a 

so cost/performance efficeint manner. In accordance 
with the present invention, there is provided a frame- 
work which can interpret either and/or both command 
sets with a single control/interpretation section con- 
tained within the rendering adapter. Therefore, there 

55 is no requirement for separate adapter control/inter- 
pretation sections on the adapter for each respective 
command, set. This advantageously results in a de- 
crease in adapter complexity, associated adapter 
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memory requirements, and in overall adapter costs. 
Multiple-command set system performance compar- 
able to that of single-command set systems is also 
maintained. 

Viewing a second aspect of the present invention, 
there is now provided a method for providing multi- 
command support in a rendering adapter, comprising: 
generating any of first command set commands and 
second command set commands by an application 
program executing on a data processing system; ini- 
tiating a transfer, by the application program, of any of 
first command set commands and second command 
set commands to a rendering adapter; receiving first 
commands of a first command set by an intermediate 
driver; providing the first commands to a rendering 
adapter; receiving second commands of a second 
command set by the intermediate driver, wherein the 
intermediate driver converts the second commands 
into resulting first command set commands; and pro- 
viding the resulting first command set commands to 
the rendering adapter. 

Viewing a third aspect of the present invention, 
there is now provided a system for providing multi- 
command support in a rendering component, com- 
prising: means for receiving first commands of a first 
command set and second commands of a second 
command set by an intermediate driver, wherein the 
intermediate driver converts any of the second com- 
mands into resulting first command set commands; 
means for providing any of the first commands, the 
second commands, and the resulting first command 
set commands to the rendering adapter; and means 
for processing any of the first commands, the second 
commands, and the resulting first command set com- 
mands by the rendering adapter. 

Viewing a fourth aspect of the present invention, 
there is now provided a system for providing multi- 
command support in a rendering adapter, comprising: 
means for receiving first commands of a first com- 
mand set and second commands of a second com- 
mand set by an intermediate driver; means for provid- 
ing the first commands, by the intermediate driver, to 
a rendering adapter; means for converting, by the in- 
termediate driver, the second commands which are 
unique to the second command set into resulting first 
command set commands; and means for providing 
the resulting first command set commands and any 
non-unique second commands, by the intermediate 
driver, to the rendering adapter. 

Viewing a fifth aspect of the present invention, 
there is now provided a method for controlling a ren- 
dering component of a data processing system, com- 
prising: receiving rendering commands by the render- 
ing component; interpreting and executing the render- 
ing commands by a single process; and maintaining 
a first state area for first state commands and a sec- 
ond state area for second state commands. 

Viewing a sixth aspect of the present invention, 



there is now provided an apparatus for controlling a 
rendering component of a data processing system, 
comprising: means for receiving rendering com- 
mands by the rendering component; means for inter- 

5 preting and executing the rendering commands by a 
single process; and means for maintaining a first state 
area for first state commands and a second state area 
for second state commands. 

!n a preferred embodiment of the present invet- 

10 nion, a device driver operates in tandem with a ren- 
dering adapter and its associated microcode. A first 
command set is defined which represents the largest 
command set being supported in the system. A sec- 
ond command set is defined which represents a sec- 
ts ond command set being supported. Rendering adap- 
ter microcode in the adapter for supporting the first 
command set is extended to support commands in 
the second command set not common to, or capable 
of being mapped into, the first command set. 

20 The device driver receives disparate data stream 

command sets generated by application programs 
and destined for the rendering adapter. !f a first com- 
mand set is received by the device driver, it is passed 
on, or transmitted, to the rendering adapter substan- 

25 tially unmodified. If a second command set command 
is received by the device driver, an attempt is made 
to map the command into a first command set com- 
mand, and then pass this mapped command to the 
rendering adapter as a resulting first command set 

30 command. If no mapping is possible, i.e, no equiva- 
lent command exists in the first command set or the 
command is not common to both command sets, then 
the received command is reformatted to conform to 
the syntax of the first command set, and contains the 

35 received second command set unique command- in- 
ternal to this reformatted package. This reformatted 
second command set unique command is then sent to 
the rendering adapter as a resulting first command set 
command. As the rendering adapter microcode has 

40 been extended beyond interpreting and executing the 
first command set, this reformatted second command 
set unique command can be processed by the same 
parser resident in the rendering adapter microcode. In 
this fashion, the microcode residing on the rendering 

45 adapter only needs to parse and route a single data 
stream syntax. 

As to the rendering adapter microcode, a first 
state is defined for the first command set to be sup- 
ported in the multi-command set adapter. The state 

so refers to such things as color, normal, positions, 
stacks of pick-identifying names, pick data, and 
stacks of matrices. A second state is defined for the 
second command set to be supported. Aspecial com- 
mand is added to the adapter command set to allow 

55 switching between these first and second states. For 
rendering commands which are common to either 
command set, this command is used to direct the 
commands to use the proper state variables. 
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Resource control commands contained within the 
two command sets were similarly modified to present 
a single, uniform data stream to the rendering adap- 
ter. As a result, only a small subset of new resource 
control command functionality was added to the adap- 
ter microcode to support the additional functionality 
contained in the second command set. 

The resulting system reduces the overall system 
complexity, the amount of adapter microcode re- 
quired, and system cost white maintaining perfor- 
mance equivalent to a single command set system, it 
will be appreciated that the present invention can be 
used for a wide variety of rendering adapters includ- 
ing, but not limited to, graphics, printer, multimedia, 
and audio. 

Preferred embodiments of the present invention 
will now be described with reference to the accompa- 
nying drawings in which: 

Figure 1 shows the interplay between a command 
generator, rendering component, and rendering de- 
vice. 

Figure 2 shows a remote command generator. 

Figure 3 shows prior art command sets. 

Figure 4 shows a unified command set built from 
disparate command sets. 

Figures 5a-5b detail the internal operation of the 
intermediate driver. 

Figure 6 details the building of a shell command 
by the intermediate driver. 

Figure 7 details the operation of expanding a sin- 
gle command into multiple commands. 

Figure 8 details the internal operation of the ren- 
dering component. 

Figure 9 is a overall system block diagram. 

Figure 1 shows a data processing system 10 and 
the interplay between an application process 11 com- 
prising a command generator 12 and an intermediate 
driver 14, and a rendering component 18. The com- 
mand generator 12 coutd be an application program 
executing on a computer. An intermediate driver 14 
receives rendering commands destined for the ren- 
dering device 16. In the preferred embodiment, inter- 
mediate driver 14 is a subroutine library which servic- 
es the appropriate rendering component 16. The in- 
termediate driver 14 manipulates and combines dis- 
parate incoming command sets and produces a single 
command set data stream. This resultant single com- 
mand set data stream is then transferred to the ren- 
dering component 16. In the preferred embodiment, 
this rendering component is a graphics adapter. How- 
ever, as will be understood by those skilled in the art, 
the concepts herein disclosed would similarly apply to 
other types of rendering devices, such as printer 
adapters, multimedia adapters, and audio adapters. 

The interface 13 between the command genera- 
tor 12 and the intermediate driver 14 is a subroutine 
calling interface, or API, in the preferred embodiment. 
An alternate embodiment would have a client/server 



interface, having a communication interface 13 be- 
tween a client 1 2 and a server 14. In this alternate em- 
bodiment, the application program 12 transmits mes- 
sages or commands to a receiving process 14 via 

5 some mechanism, such as pipes, sockets, streams, 
shared memory, or semaphores, as is generally 
known to those of ordinary skill in the art. The output 
of the intermediate device 1 4 is a series of commands 
which are transferred along a channel, bus, or corn- 
to munication link to a rendering adapter 16 via conven- 
tional transfer methods 18. Such methods include I/O 
port addressing, memory mapped I/O, and the like. 
These commands can contain various kinds of infor- 
mation, such as resource control commands, render- 

15 ing instructions, or data. 

The rendering device 16 comprises various sub- 
assemblies in the preferred embodiment. Adapter mi- 
crocode executing on a general purpose digital signal 
processor (DSP) and hardware/firmware embodied in 

20 special purpose gate arrays (bus interface chips) pro- 
vide the interface function at 17. The DSP connects 
to a rendering subsystem 19 using conventional inter- 
nal wiring 20. The rendering subsystem 1 9, which pro- 
vides rasterization in the preferred embodiment, com- 

25 prises application specific VLSI chips, banks of 
VRAM/DRAM memory components, and digita!-to- 
analog (DAC) chips. The rendering subsystem 19 
drives a CRT display 21 in the preferred embodiment. 
However, there could similarly be a print head at 21 

30 in an alternate embodiment, with the rendering sub- 
system 1 9 further comprising control for paper manip- 
ulation using conventional electo-mechanical compo- 
nents and techniques. 

A rendering context manager 22 is similarly situ- 

35 ated on the transfer means 1 8. The rendering context 
manager is a separate process which allows for mul- 
tiple applications to use a single rendering adapter, by 
providing conventional multiprocessing support 

Figure 2 shows another embodiment of the inven- 

40 tion wherein a command generator/driver subsystem 
1 1 is located in a data processing system 24 distinct 
from the processing system 28 containing the render- 
ing component 16. Conventional communications 
methods 38 are used to connect, or establish a ses- 

45 sion, between communication interfaces 30 and 40. 
These communication interfaces connect to the ren- 
dering device 34 at 36, and the command generator 
11 at 42. it should be understood that the communi- 
cation interfaces at 30 and 40 may be simple commu- 

so nication adapters, or may be more sophisticated sub- 
systems having computer controlled queuing, sched- 
uling, etc. as is commonly known in the art of remote 
data processing and internetworking. 

Figure 3 indicates how prior art systems process- 

55 ed differing command sets. Each distinct command 
set 44 and 46 are processed by separate and distinct 
processes on a rendering adapter. The present inven- 
tion described herein merges these disparate com- 
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mand sets 44 and 46 into a single command set hav- 
ing various components contained within. As shown in 
Figure 4, a single command set 49 results from merg- 
ing the differing command sets 44 and 46 of Figure 3. 
First command set commands 46 and second com- 
mand set commands 44 are merged, with commands 
common to both command sets being shown at 48. 
These common commands exist in both the first com- 
mand set 46 and the second command set 44. 

Figure 5a details the operation of the combined 
process 11 of Figure 1. This combined process con- 
sists of an application program or command generator 
12, an intermediate driver 14 and their interconnec- 
tion via a subroutine calling interface 13 (see Figure 
1). When certain commands generated by 12 are 
known to be a part of the first command set 46 of Fig- 
ure 4, such commands cause control to be passed to 
60 of Figure 5a, where the command is transferred on 
to the rendering component 1 6 of Fig. 1 without mod- 
ification. It will be understood that any slight modifi- 
cations to the command would also be possible and 
not deviate from the scope and spirit of this invention. 
For example, a bit could be turned on in a defined 
field indicating the command had been queried and 
left unmodified by the device driver. The primary dis- 
tinction here is that the general content of the received 
command dees not need to be substantially modified 
prior to passing the command to the rendering com- 
ponent 16 of Figure 1 . 

Likewise, certain commands generated by 12 are 
known to be a part of the second command set 44 of 
Figure 4. Such commands cause control to be passed 
to 58 (the internal function to be later described in 
more detail), where the received command is embed- 
ded within a shell structure having syntax which con- 
forms to a first command set. Control then passes to 
60, where the resulting first-command-set-syntax- 
conforming command is transferred to the rendering 
component 16 of Fig. 1. 

Likewise, certain commands generated by 12 are 
known to be mappable into an equivalent first com- 
mand set command 48 of Fig. 4. If so, control passes 
to 56 where the command is mapped to a resulting 
first command set command. The mapping is accom- 
plished using standard programming techniques by 
building the equivalent first command set command 
and placing parameters in the locations defined for 
the first command set command. The resulting first 
command set command is then transferred to the ren- 
dering component at 60. 

Likewise, certain commands generated by 12 are 
known to be convertible to combinations of a first and 
a second command set. If so, control passes to 54 
where a significant amount of processing is done to 
convert the incoming command into one or more of 
the commands 44, 46, and/or 48 (the internal opera- 
tion to be later described herein). After such process- 
ing and conversion is complete, control is passed di- 



rectly to 60, or to 56 or 58, where relatively minor map- 
ping and encapsulation is performed before passing 
control to 60. 

Resource control commands contained within the 

5 two command sets are similarly modified as descri- 
bed above to present a single, uniform data stream to 
the rendering adapter. As a result, only a small subset 
of new resource control command functionality is 
needed in the adapter microcode to support the addi- 

10 tional functionality contained in the second command 
set 

The conceptual model for performing the above 
is shown in Fig. 5b. Commands are received from the 
command generator at 50. A determination is made at 

15 51 as to whether this received command is a part of 
the first command set (46 of Fig . 4) or a common com- 
mand (48 of Fig. 4). If so, processing continues at 60 
where the command is transferred to the rendering 
component without modification. If the query at 51 in- 

20 dicates the received command is a part of the second 
command set (44 of Fig. 4), processing continues to 
52, where a determination is made on whether the re- 
ceived command can be mapped into an equivalent 
first command set command 48 of Fig. 4. If so, control 

25 passes to 56 where the command is mapped to a re- 
sulting first command set command. This resulting 
first command set command is then transferred to the 
rendering component at 60. If the query at 52 indi- 
cates the received command cannot be mapped into 

30 an equivalent first command set command, it is deter- 
mined at 53 if the received command can be convert- 
ed to combinations of a first and a second command 
set commands. If so, this conversion is accomplished 
at 54, after which the resulting combination of com- 

35 mands are processed by 56, 58 or 60 as described 
above. If the determination at 53 indicates this is a 
unique second command set command 44 of Fig. 4, 
processing at 58 embeds the received command with- 
in a shell structure having syntax which conforms to 

40 a first command set command. Processing at 60 then 
passes this resulting first command set command 
(the unique second command set command with shell 
structure) on to the rendering component. It should be 
reiterated that the above is a conceptual model of the 

45 internal process, which can be implemented in nu- 
merous ways using programming techniques com- 
monly known, such as If-Then-Else logic. Switch 
statements, Case statements, or table-lookup techni- 
ques. 

50 The function performed by 58 of Figs. 5a and 5b 

will now be described in reference to Figure 6. As pre- 
viously described, the command process 11 compris- 
es a command generator 12 coupled to an intermedi- 
ate driver 14 by transfer means 13. The command 

55 generator 12 generates a series of commands 120- 
1 28 destined for a rendering adapter 1 6. To exemplify 
the building of a shell command as a result of a series 
of individual commands, a display_polyline command 
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is shown. Second command set commands (44 of Fig. 
4) are generated by the command generator 12. A be- 
ginjine command 120 is initially generated, followed 
by a series of vertex commands 122, 124 and 126 
having vertex coordinates, and ending with an endji- 
ne command 128. When the begin Jine command 120 
is received by the intermediate driver 1 4, a sheli struc- 
ture as indicated at 130 is created. This shell structure 
will be ultimately passed on to the rendering adapter 
16. The shell structure is initialized with a length at 
1 32, an opcode at 1 34 indicating a polyline command, 
the number of points contained within the polyline at 
136, and flags at 138. As each subsequent vertex 
command 122, 124, and 126 is received by the inter- 
mediate driver 14, the coordinate data contained with 
the vertex command is placed in the shell structure at 
140, 142, and 144 respectively. The length 132, num- 
ber of points 1 36, and flags 1 38 are also updated 
when inserting the vertex data. Finally, when the end- 
_iine command 128 is received by the intermediate 
driver 14, the processing in block 58 of Figure 4 ter- 
minates, and control passes to block 60 of Figure 4, 
where the shell structure 130 (resulting first- 
command-set-syn tax-conforming command) is trans- 
ferred via 18 to the rendering component 16. Other 
second command set commands 58 can be process- 
ed in a similar manner, using programming techni- 
ques generally known to those of ordinary skill in the 
art 

The function of block 54 of Figure 5a will now be 
described. This block converts received commands 
into a combination of first and second command set 
commands. Referring to Figure 7, a sample control 
flow is shown which exemplifies the function of block 
54. In this example, a set_pattern command is re- 
ceived at 150. This results in block 54 searching in 
system memory at 1 52 to find a pattern as previously 
defined by a define_pattern command. A setup_lo- 
ad_attributes command is generated at 154, (which is 
a second command set command 44 of Fig. 4) to ob- 
tain the pattern attributes. A write_attributes com- 
mand is then generated at 1 56 (which is also a second 
command set command 44 of Fig. 4) to write the pat- 
tern and its size to the rendering component 16. Final- 
ly, a set_interior__style command is generated at 158 
(which is a first command set command 58 of Fig. 4), 
which instructs the rendering adapter to use this pat- 
tern as the interior style to be used in its subsequent 
rendering operations. Program control is returned at 
160. The above description exemplifies the operation 
of block 54 in combination with blocks 56 and 58 of 
Fig. 5a, and how a single command can cause vary- 
ing combinations of first and second command set 
commands to be issued to the rendering component. 
It will be understood to those of ordinary skill in the art 
that other commands received at 54 could be similarly 
processed using these and other conventional pro- 
gramming techniques. Upon block 54's completion, 



control can either pass directly to 60 (Fig. 5a) if no fur- 
ther processing is required, or to either block 56 or 58 
if processing as previously described for these blocks 
is required (e.g. mapping a 48 command or encapsu- 

5 lating a series of second command set commands 44 
into a first command set command 46). 

Turning now to Figure 8, the rendering compo- 
nent operation will be described. In the preferred em- 
bodiment, the primary control for the rendering com- 

10 ponent is a microprocessor or microcontroller having 
microcode 74 associated therewith. This microcode is 
conceptually divided into three components. Com- 
mands unique to the first command set are processed 
by microcode 80. Commands unique to the second 

15 command set are processed by microcode 84. Com- 
mands which are common(i.e. non-unique com- 
mands) to both the first and second command sets 
are processed by microcode 82 in the preferred em- 
bodiment. Alternate embodiment could perform this 

20 via a VLSI gate array. When commands are received 
by the rendering component at 76, a query is made at 
78 to determine the appropriate microcode 80, 82, or 
34 to invoke. Query 78 is also used to control local 
memory 92 as follows. A first state 86 is defined for 

25 the first command set to be supported in the multi- 
command set adapter. The state refers to such things 
as color, normal, positions, stacks of pick-identifier 
names, pick data, and stacks of matrices, for exam- 
ple. A second state 88 is defined for the second com- 

30 rnand set to be supported. A special command is add- 
ed to the adapter command set to allow switching at 
90 between these first and second states. For render- 
ing commands which are common to either command 
set 82, this command is used to direct the commands 

35 to use the proper state variables 86 or 88. 

Figure 9 details the overall system environment 
1 00. A keyboard 102, central processing unit 104, ran- 
dom access storage 106, a nonvolatile storage device 
108, and a rendering adapter 110 attached to a ren- 

40 dering output device 112 are interconnected via a bus 
114. The hardware devices listed may or may not fur- 
ther include appropriate adapters required for direct 
bus attachment. In an alternate embodiment, the key- 
board 1 02 and/or random access storage 106 may at- 

45 tach directly to the central processing unit 104 in order 
to achieve increased performance. In the preferred 
embodiment, the rendering output device 112 is a dis- 
play and the rendering adapter 110 is a graphics 
adapter, In an alternate embodiment, the rendering 

so output device 1 1 2 is a printer, and the rendering adap- 
ter 110 is a printer adapter. Likewise, in an alternate 
embodiment, the rendering adapter 110 may attach 
directly to the CPU 104 in order to achieve enhanced 
performance. 

55 
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Claims 



2. 



A method of providing commands to a rendering 
adapter, comprising: 

receiving first commands of a first com- 
mand set in an intermediate driver; 

transferring the first commands from the 
intermediate driver to a rendering adapter; 

receiving second commands of a second 
command set in the intermediate driver; 

converting, in the intermediate driver, the 
second commands which are unique to the sec- 
ond command set into resulting first command 
set commands; and 

transferring the resulting first command 
set commands and any non-unique second com- 
mands from the intermediate driver to the render- 
ing adapter. 

A method as claimed in Claim 1 wherein the inter- 
mediate driver is a device driver. 



3. A method as claimed in Claim 2 wherein the trans- 
ferring is achieved by using memory-mapped 
I/O. 

4. A method as claimed in Claim 3 wherein the trans- 
ferring is achieved by using I/O port addressing. 

5. Apparatus for providing commands to a rendering 
adapter, comprising: 

An intermediate driver having means for 
receiving first commands of a first command set 
and second commands of a second command set 
and means for converting the second commands 
which are unique to the second command set into 
resulting first command set commands; 

means for transferring the first com- 
mands, from the intermediate driver, to a render- 
ing adapter; and 

means for transferring the resulting first 
command set commands and any non-unique 
second commands, from the intermediate driver, 
to the rendering adapter. 

6. Apparatus as claimed in Claim 5 wherein the ren- 
dering adapter is a graphics adapter. 
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ceiving first commands of a first command set 
and second commands of a second command set 
by an intermediate driver, wherein the intermedi- 
ate driver converts any of the second commands 
into resulting first command set commands, and 
means for transferring any of the first commands, 
the second commands and the resulting first 
command set commands to the rendering adap- 
ter. 

9. A method for providing multi-command support in 
a rendering adapter, comprising: 

receiving first commands of a first com- 
mand set by an intermediate driver and providing 
the first commands to a rendering adapter; and 

receiving second commands of a second 
command set by the intermediate driver, convert- 
ing any of the second commands into resulting 
first command set commands, and providing the 
resulting first command set commands to the ren- 
dering adapter. 

10. A system for providing multi-command support in 
a rendering adapter, comprising: 

means for receiving first commands of a 
: first command set and second commands of a 
second command set by an intermediate driver, 
wherein said intermediate driver converting any 
of said second commands into resulting first com- 
mand set commands; and 

means for providing any of said first com- 
mands, said second commands and said result- 
ing first command set commands to said render- 
ing adapter. 



7. Apparatus as claimed in Claim 5 wherein the ren- 
dering adapter is a printer adapter. 
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8. A data processing system comprising: 
a keyboard; 

a central processing unit; 

memory means for storing data; 55 

nonvolatile storage; 

a rendering output device; and 

a rendering adapter having means for re- 

7 
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